Packet processing systems typically transfer packets between network interface card hardware buffers and transmit (tx) and receive (rx) buffers based on polling of the buffer levels or periodic interrupts. However “spikes” or surges in traffic transiting the buffers may occur, due to internal (application delays, processor delays, etc.) or external (network congestion, transmission errors, etc.) causes. For example, if traffic is stalled by an external intermediary device and then released, it may arrive in a reception rush or spike or a number of packets n per time t greatly exceeding an average rate. Conversely, a spike may also result from the buffer not being emptied as quickly as traffic is received: if there are not enough CPU cycles to drain the received packets from the network interface hardware queue, or if the draining rate is slower than the arrival rate, then the buffer may effectively experience a traffic spike. Thus, a spike may refer to an increase in data being buffered, caused by traffic arriving at an increased rate, and/or traffic being drained from a buffer at a decreased rate. Similarly, spikes may occur in transmission buffers, with data “received” from internal applications for transmission to external devices. Accordingly, spikes in “received” traffic may refer to traffic flows transiting a network interface and buffers in either direction, and may refer to the traffic being received at the buffer, regardless of internal or external source.
In many instances, the buffers are unable to cope with this increase in data, and as a result, newly arriving packets may be dropped. Various attempts to mitigate this issue include dropping packets having a lowest priority or by other such metrics, but this requires retransmission, additional latency, increased bandwidth requirements, and may result in unpredictable system behavior.